-
Notifications
You must be signed in to change notification settings - Fork 410
CLDR-16855 Survey Tool account creation date #5145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
-New column firstdate in db cldr_users table, add and populate if not present when ST starts up -Already existing users get approximate dates based on the first versions in which they voted, according to vote tables from version 25 and later; users who never voted get null meaning unknown -When new user accounts are added, firstdate will get the creation date -Display as (account created ...) in Account Settings, with indication if approximate or unknown -Rename Java User.last_connect to User.lastlogin for consistency with lastlogin in db cldr_users table -New convenience function DBUtils.addColumnIfMissing; slightly refactor STFactory to use it -Change some items in UserRegistry from public to private -Minor edits for consistency, such as uppercase for SQL keywords -Fix recently added bug in cldrAddUser.mjs and cldrAddUser.mjs: set orgName if not admin -Comments
-Fix comments and a variable name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looksgood. Would be good to test a blank-slate startup (with no DB)
Excellent question. I've just tried that both on main branch and on this branch. I tried it two ways: (1) with empty cldrdb; (2) with non-existent cldrdb. In all of these scenarios, including with main branch, ST fails to start. What's the expected/desired behavior? I imagine that with an empty db it should start with a clean slate and the tables should get initialized appropriately. With non-existent db, I imagine there may be security/permissions problems with automatic creation of a new db. |
|
With some debugging turned on, I'm seeing contradictions on start-up, on main branch, with empty DB: [INFO] [WARNING ] table cldr_users already existed. |
|
@srl295 I suspect a bug involving I'm seeing: Notice that TABLE_CAT is "cldrtest" NOT "cldrdb". If I run ST again (without emptying the db), TABLE_CAT is "cldrdb" and the table really does exist. So there seems to be some kind of a delayed effect, and the problem involves this name "cldrtest". Do you have any idea where the name "cldrtest" comes from? I don't find it in the Java code. |
|
I made a new ticket for the preexisting empty-DB bug: https://unicode-org.atlassian.net/browse/CLDR-19085 |
-New column firstdate in db cldr_users table, add and populate if not present when ST starts up
-Already existing users get approximate dates based on the first versions in which they voted, according to vote tables from version 25 and later; users who never voted get null meaning unknown
-When new user accounts are added, firstdate will get the creation date
-Display as (account created ...) in Account Settings, with indication if approximate or unknown
-Rename Java User.last_connect to User.lastlogin for consistency with lastlogin in db cldr_users table
-New convenience function DBUtils.addColumnIfMissing; slightly refactor STFactory to use it
-Change some items in UserRegistry from public to private
-Minor edits for consistency, such as uppercase for SQL keywords
-Fix recently added bug in cldrAddUser.mjs and cldrAddUser.mjs: set orgName if not admin
-Comments
CLDR-16855
ALLOW_MANY_COMMITS=true